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(57) Abstract 

An object oriented programming 
(OOP) based messaging interface method 
for use between a client application and a 
messaging service on a computer system is 
provided. The method includes providing: 
a message class which has data members 
and member functions related to a message 
in the messaging service, a message bin 
class which has data members and member 
functions related to holding the message, 
and a message bin name class which 
has data members and member functions 
related to identifying a message bin object 
instantiated from the message bin class. 
Subsequently, a messaging interface object 
for the message is generated as an instance 
of one or more of the provided classes. 
This generated messaging interface object 
furnishes the client application with protocol 
independent access to the messaging service. 
In addition, a storage device readable by 
a computer system for implementing the 
OOP-based messaging interface method 
and an OOP-based messaging interface aTe 
provided. 
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AN OBJECT ORIENTED PROGRAMMING BASED MESSAGING INTERFACE SYSTEM AND METHOD 

Field Of The Invention 

5 

Tne present invention relates generally to a messaging interface 
to an electronic messaging system for a communication network. More 
particularly, the present invention relates to such a messaging interface 
as implemented in an object oriented programming based 
10 environment. 

Background of the Invention 

A variety of different messaging systems are known which are 

15 used to transrer data between different users connected to a common 

network. For example, a number or electronic mail systems are used to 
exchange maii message between human users typically connected to 
some form of a communication network via a personal computer. Use 
of such messaging systems are increasingly used in a number of 

20 environments over a wide variety of different type of networks. 

The types or users connected to the network are also increasingly 
adding complexity to the network. For example, one user mav be 
connected to the network via one type of computing platform while 
another user mav use a different type of computing platform. This 

25 places an increased burden on the messaging systems to handle 

messages generated using different software and hardware having 
different messaging protocols. 

Moreover, multiple network systems are being increasingly tied 
together (e.g., the Internet), effectively forming larger networks 

30 connecting systems using even more disparate hardware and software. 
The messaging systems may be either directly connected to the system 
using a gateway to allow messages to be routed between the different 
systems, or indirectly connected (i.e., messaging systems which 
communicate through a third system and which are not directly 

35 connected to the same third system). 

Current messaging systems are unable to efficiently handle 
messaging between the various types of user systems. As a result, the 
type of data which may be transferred must be limited to common 
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rormats (e.g., ASCII text) to be handled by the different system. The data 
to be transferred across such heterogeneous environments looses 
fidelity as a result or" translations and transformations to the lowest 
common denominator capable or being handled bv the different 
5 systems. Proper messaging over such disparate systems is also hindered 
by different message protocols. For example, there mav be several vvavs 
to address a single recipient, adding still further complexity' to the 
system. 

In order tc address the above problems, attempts have been made 

10 to provide application programs capable of operating on different user 
systems and freely exchanging messages therebetween. Such 
approaches attempt to specifically address the different types of systems 
being used to provide messaging capabilities. -Another approach is to 
standardize or limit the types or messaging systems used on a network. 

1? This, however, limits the functionality of the network and the 
messaging systems. 

Object oriented programming (OOP) has become increasingly 
used to develop complex applications. As OOP moves toward the 
mainstream of software design and development, electronic messaging 

20 systems, like e-mail, will need to be adapted to make use of the benefits 
of OOP. A need exists for these principles of OOP to be applied to a 
messaging interface of an electronic messaging system such that a set of 
OOP classes and objects for messaging interface can be provided. 

OOP is a process of developing computer software usinp objects, 

25 including the steps of analyzing the problem, designing the svstem, and 
constructing the program. .An object is a software package that contains 
both data and a collection of related structures and procedures. Since it 
contains both data and a collection of structures and procedures, it can 
be visualized as a self-sufficient component that does not require other 

30 additional structures, procedures or data to perform its specific task. 
OOP, therefore, views a computer program as a collection of largelv 
autonomous components, called objects, each of which is responsible 
for a specific task. This concept of packaging data, structures, and 
procedures together in one component or module is called 

35 encapsulation. 

OOP components, in general, are reusable software modules 
which present an interface that conforms to an object model and which 
are accessed at run-time through a component integration architecture. 
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A component integration architecture is a set or architecture 
mechanisms which allow software modules in different process spaces 
to utilize each other's capabilities or functions. This is generally done by 
assuming a common component object model on which to build the 
5 architecture. 

It is worthwhile to differentiate between an object and a class of 
objects at this point. An object is a single instance of the class of objects, 
which is often just called a class. A class of objects can be viewed as a 
blueprint, from which many objects can be formed. 

10 OOP allows the programmer to create an object that is a part of 

another object. For example, the object representing a piston engine is 
said to have a composition-relationship with the object representing a 
piston. In realitv, a piston engine comprises a piston, valves and many 
other components; the fact that a piston is an element of a piston engine 

15 can be iogicaliv and semantically represented in OOP bv two objects. 

OOP also allows creation of an object that 'depends from'* 
another object. If there are two objects, one representing a piston engine 
and the other representing a piston engine wherein the piston is made 
of ceramic, then the relationship between the two objects is not that of 

20 composition. A ceramic piston engine does not make up a piston 

engine. Rather it is merely one kind of piston engine that has one more 
limitation than the piston engine; its piston is made of ceramic. In this 
case, the object representing the ceramic piston engine is called a 
derived object and it inherits all of the aspects of the object representing 

25 the piston engine and adds further limitation or detail to it. The object 
representing the ceramic piston engine "depends from" the object 
representing the piston engine. The relationship between these objects 
is called inheritance. 

When the object or class representing the ceramic piston engine 

30 inherits all of the aspects of the objects representing the piston engine, it 
inherits the thermal characteristics of a standard piston defined in the 
piston engine class. However, the ceramic piston engine object 
overrides these thermal characteristics with those specific to a ceramic 
piston which are typically different from those associated with a metal 

35 piston. It skips over the original and uses new functions related to 

ceramic pistons. Different kinds of piston engines will have different 
characteristics, but may have the same underlying functions associates 
with it (e.g., how many pistons in the engine, ignition sequences, 
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lubncation. etc.}. To access each of these functions in any pis ton engine 
object, a programmer would cail the same functions with the same 
names, but each type of piston engine may have different /overriding 
implementations of functions behind the same name. This ability to 
5 hide different implementations of a function behind the same name is 
called polymorphism and it greatly simplifies communication among 
objects. 

With the concepts of composition-relationship, encapsulation, 
inheritance and polymorphism, an object can represent just about 
10 anything in the real world. In fact, our logical perception of the reality 
is the only limit on determining the kinds of things that can become 
objects in object-oriented software. Some typical categories are as 
follows: 

• Objects can represent physical objects, such as automobiles in a traffic- 
15 flow simulation, electrical components in a circuit-design program. 

countries in an economics model, or aircraft in an air-traffic-control 
system . 

• Objects can represent elements of the computer-user environment 
such as windows, menus or graphics objects. 

20 • An object can represent an inventory, such as a personnel file or a 
table of the latitudes and longitudes of cities. 

• An object can represent user-defined data types such as time, angles, 
and complex numbers, or point on the plane. 

2d With this enormous capability or an object to represent )ust about 

any logically separable matters, OOP allows the software developer to 
design and implement a computer program that is a model of some 
aspects of reality, whether that reality is a physical entity, a process, a 
system, or a composition of matter. Since the object can represent 

30 anything, the software developer can create an object which can be used 
as a component in a larger software project in the future. 

If 90% of a new OOP software program consists of proven, 
existing components made from preexisting reusable objects, then only 
the remaining 10% of the new software project has to be written and 

35 tested from scratch. Since 90% already came from an inventory of 

extensively tested reusable objects, the potential domain from which an 
error could originate is 10% of the program. As a result, OOP enables 
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software developers to buiid objects out or other, previously built, 
objects. 

This process closely resembles complex machinery being built out 
of assemblies and sub-assemblies. OOP technology/therefore, makes 
5 software engineering more like hardware engineering in that software 
is built from existing components, which are available to the developer 
as objects. All this adds up to an improved qualitv of the software as 
well as an increased speed of its development. 

Programming languages; are beginning to fully support the OOP 

10 principles, such as encapsulation, inheritance, polymorphism, and 

composition-relationship. With the advent of the C++ language, many 
commercial software developers have embraced OOP. C++ is an OOP 
language that offers a fast, machine-executable code. Furthermore, C++ 
is suitable for both commercial-application and systems-programming 

15 projects. For now, C-+ appears to be the most popular choice among 
many OOP programmers, but rhere is a host of other OOP languages, 
such as Smalltalk, common lisp object system (CLOS), and Eiffel. 
Additionally, OOP capabilities are being added to more traditional 
popular computer programming languages such as Pascal. 

-° The benefits of class libraries can be summarized, as follows: 

• Objects and their corresponding classes break down complex 
programming problems into many smaller, simpler problems. 

♦ Encapsulation enforces data abstraction through the organization of 
data into small independent objects that can communicate with each 

15 other. Encapsulation protects the data in an object from accidental 

damage, but allows other objects to interact with that data bv calling 
the object s member functions and structures. 

• Subclassing and inheritance make it possible to extend and modifv 
objects through deriving new kinds of objects from the standard 

50 * classes available in the system. Thus, new capabilities are created 
without having to start from scratch. 

* Polymorphism and multiple inheritance make it possible for 
different programmers to mix and match characteristics of many 
different classes and create specialized objects that can still work with 

>5 related objects in predictable wavs. 

* Class hierarchies and containment hierarchies provide a flexible 
mechanism for modeling real-world objects and the relationships 
amone them. 
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10 



These libraries or reusable ciasses are useful in many situations, 
but they also have some limitations. For example: 

• Complexity. In a complex system, the class hierarchies tor related 
ciasses can become extremely, contusing, with many dozens or even 
hundreds of classes. 

• Flow of control. A program written with the aid of class libraries is 
still responsible for the flow or control (i.e., it must control the 
interactions among all the objects created from a particular library). 
The programmer has to decide which functions to call at what times 
for which kinds of objects. 

• Duplication of effort. Although class libraries allow programmers to 
use and reuse many small pieces of code, each programmer puts 
those pieces together in a different way. Two different programmers 

15 can use the same set of class libraries to write two programs that do 
exactly the same thing but whose internal structure {i.e.. design) may- 
be quite different, depending on hundreds of small decisions each 
programmer makes along the way. Inevitably, similar pieces of code 
end up doing similar things in slightly different ways and do not 

20 work as well together as they should. 

Class libraries provide lots of flexibility. As programs grow more 
complex, more programmers are forced to reinvent basic solutions to 
basic problems over and over again. A relatively new extension of the 
ciass library idea is to have a framework of class libraries. This 
framework is more complex and consists of significant collections of 
collaborating classes that capture both the small scale patterns and 
major mechanisms that implement the common requirements and 
design in a specific application domain. They were first developed to 
free application programmers from the chores involved in displaying 
menus, windows, dialog boxes, and other standard user interface 
elements for personal computers. 

Frameworks also represent a change in the way programmers 
think about the interaction between the code they write and code 
written by others. In the early days of procedural programming, the 
programme; called libraries provided by the operating system to 
perform certain tasks, but basically the program executed down the page 
from start to finish, and the programmer was solely responsible for the 
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rlovv or controi. This was appropriate for printing out paychecks, 
calculating a mathematical table, or solving other problems with a 
program that executed in just one vvav. 

The development of graphical user interfaces began to turn this 
5 procedural programming arrangement inside out. These interfaces 
allow the user, rather than program logic, to drive the program and 
decide when certain actions should be performed. Today, most personal 
computer software accomplishes this by means of an event loop which 
monitors the mouse, keyboard, and other sources of external events and 
10 calls the appropriate parts of the programmers code according to actions 
that the user performs. The programmer no longer determines the 
order in which events occur. Instead, a program is divided into separate 
pieces that are called at unpredictable times and in an unpredictable 
order. By relinquishing control in this wav to users, the developer 
:5 creates a program that is much easier to use. Nevertheless, individual 
pieces of the program written by the developer still call libraries 
provided by the operating system to accomplish certain tasks, and the 
programmer must still determine the flow of control within each piece 
after it s called by the event loop. Application code still "sits on top of" 
20 the system. 

Even event loop programs require programmers to write a lot of 
code that should not need to be written separately for every application. 
The concept or an application rramework carries the event loop concept 
further. Instead of dealing with all the nuts and bolts of constructing 
25 basic menus, windows, and dialog boxes and then making these things 
all work together, programmers using application frameworks start 
with working application code and basic user interface elements in 
place. Subsequently, they build from there by replacing some of the 
generic capabilities of the framework with the specific capabilities of the 
30 intended application. 

Application frameworks reduce the total amount of code that a 
programmer has to write from scratch. However, because the 
rramework is really a generic application that displays such as windows, 
supports copy and paste, and so on, the programmer can also relinquish 
3? control to a greater degree than event loop programs permit. The 
framework code takes care of almost all event handling and flow of 
control, and the programmer s code is called only when the framework 
needs it (e.g., to create or manipulate a proprietary data structure). 
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A programmer writing a framework program not only 
relinquishes control to the user (as is also true for event loop programs) 
but also relinquishes the detailed flow of control within the program to' 
the framework. This approach allows the creation of more complex 
systems that work together in interesting ways, as opposed to .solated 
programs, having custom code, being created over and over again for 
similar problems. 

A framework basically is a collection of cooperating classes that 
make up a reusable design solution for a given problem domain. It 
typically includes objects that provide default behavior (e.g., menus and 
windows), and programmers use it by inheriting some of that default 
behavior and overriding other behavior so that the framework calls 
application code at the appropriate times. 

There are three main differences between frameworks and class 
Ir libraries: 

• Behavior versus protocol. Class libraries are essentially collections of 
behaviors that you can call when you want those individual 
behaviors in your program. A framework, on the other hand, 
provides not only behavior but also the protocol or set of rules that 
govern the ways in which behaviors can be combined, including 
rules for what a programmer is supposed to provide versus what the 
framework provides. 
. Call versus override. With a class library, the code the programmer 
writes instantiates objects and calls their member functions. It's 
possible to instantiate and call objects in the same way with a 
framework (i.e., to treat the framework as a class library), but to take 
full advantage of a frameworks reusable design, a programmer 
typically writes code that overrides and is called by the framework. 
The framework manages the flow of control among its objects. 
Writing a program involves dividing responsibilities among the 
various pieces of software that are called by the framework rather 
than specifying how the different pieces should work together. 
► Implementation versus design. With class libraries programmers 
reuse only implementations, whereas with frameworks they reuse 
design. -A framework embodies the way a family of related programs 
or pieces of software work. It represents a generic design solution 
that can be adapted to a variety of specific problems in a given 
domain. For example, a single framework can embody the way a user 
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intcrface works, even though two different user interfaces created 
with the same framework might solve quite different interface 
problems. 

? Thus, through the development of frameworks for solutions to 

various problems and programming tasks, significant reductions in the 
design and development effor: for software can be achieved. 

A more detailed description of OOP is given bv Cotter, et al, 
Inside Talieer.: Technolog y, Addison-Wesiey Publishing (1995). 

10 incorporation of the principles of OOP in a messaging interface 

allows the messaging system to be more tightly integrated with other 
OOP-based applications and operating systems. In addition, the 
maintenance and development: effort required by such an OOP-based 
messaging interface will* likely be significantly less than complex 

15 procedural procramming-based messaging interfaces. This is because 
parts (i.e., objects or classes) of the OOP-based messaging interface may 
be modified as needed and automatically propagated throughout the 
software code without affecting the rest of the messaging interface. In 
contrast, an entire procedural programming-based messaging interface, 

20 as conventionally produced, must be completely tested and debugged 
each time any modification is made to the software code, because each 
modification must be manually propagated to different parts of the 
software code. 

The present invention provides a solution to these and other 
2? problems, and offers other advantages over the prior art. 

Summary of the Invention 

The present invention relates to an OOP-based messaging 
30 interface between a client application and an electronic messaging 
system. 

In accordance with one aspect of the invention, a messaging 
interface between a client application and a messaging service for a 
computer system is provided. The messaging interface includes a 
35 storage device, in the computer system, which stores OOP-based classes. 
These stored classes include: a message class which has data members 
and member functions related to a message in the messaging service, a 
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message bin class which has data members and member functions 
related to holding the message, and a message bin name class which has 
data members and member functions related to identifying a message 
bin object instantiated from the message bin class. The messaging 
5 interface aiso includes a processor operatively coupled to the storage 
device which generates a messaging interface object for the message as 
an instance of one or more of the stored classes. This generated 
messaging interface object furnishes the client application with protocol 
independent access to the messaging service. 

10 This aspect of the invention also can be implemented as an OOP- 

based messaging interface method for use between a client application 
and a messaging service on a computer system. This method is 
performed by device-implemented steps in a series of distinct processing 
steps that can be implemented in one or more processors. A message 

!:> class which has data members and member functions related to a 

message in the messaging service is provided. Also, a message bin class 
which has data members and member functions related to holding the 
message is provided. In addition, a message bin name class which has 
data members and member functions related to identifying a message 

20 bin object instantiated from the message bin class is provided. A 

messaging interface object for the message is generated as an instance of 
one or more of the provided classes. This messaging interface object 
furnishes the ciient application with protocol independent access to the 
messaging service. 

2d These and various other features as well as advantages which 

characterize the present invention will be apparent upon reading of the 
following detailed description and review of the associated drawings. 

Brief Description of the Drawings 

30 

FIG. 1 is a block diagram of a personal computer svstem in 
accordance with a preferred embodiment of the present invention. 

FIG. 2 is a block diagram of a route a message might take from an 
originator to a recipient. 
35 FIG. 3 is a block diagram showing the transport of data through a 

messaging system. 

FIG. 4 is a block diagram of a typical messaging system. 
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FIG. 5 is a block diagram or components of a preferred 
embodiment messaging system architecture. 

FIG. 6 is a block diagram or a preferred embodiment object 
oriented programming based messaging interface used in the computer 
5 svstem shown in FIG. 1. 

FIG. 7 is a block diagram of the ciass hierarchy for the preferred 
embodiment messaging interface. 

FIG. 8 is a block diagram of an example Iife-cylce of a message in 
the messaging system. 

FIG. 9 is a block diagram of the class hierarchy for the preferred 
embodiment message bin classes. 

FIG. 10 is a block diagram of the ciass hierarchy for the preferred 
embodiment message bin name classes. 

FIG. 11 is a block diagram of the ciass hierarchy for the preferred 
embodiment message classes. 

FIG. 12 is a flowchart of the preferred embodiment object oriented 
programming based messaging interface method used in the computer 
system shown in FIG. 1. 

20 Detailed Description 

The preferred embodiment of the present invention is preferably 
practiced in the context of an operating system resident on a personal 
computer such as the IBM® PS/2® or Apple® Macintosh® computer. 
25 A representative hardware environment is depicted in FIG. 1, which 
illustrates a typical hardware configuration of a workstation in 
accordance with the preferred embodiment having a central processing 
unit 110, such as a microprocessor, and a number of other units 
interconnected via a system bus 112. The workstation shown in FIG. 1 
includes a Random Access Memory (RAM) 114, Read Only Memory 
(ROM) 116, an I/O adapter 118 for connecting peripheral devices such as 
disk storage units 120 to the bus 112, a user interface adapter 122 for 
connecting a keyboard 124, a mouse 126, a speaker 128, a microphone 
132, and /or other user interface devices such as a touch screen (not 
shown) to the bus 112, communication adapter 134 for connecting the 
workstation to a communication network (e.g., a data processing 
network) and a display adapter 136 for connecting the bus 112 to a 
display device 138. The workstation typically has resident thereon an 
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operatmg system such as the IBM OS/2® operating system or the Apple 
System /7® operating system. 

Store and forward messaging is a class of communication 
involving asynchronous transmission and reception of data. 
5 Asynchronous communication allows message transfer even when the 
originator and the recipient are not simultaneously active. The term 
"messaging" sometimes will be used hereinafter for store and forward 
messaging. 

FIG. 2 is a block diagram showing a route that a message might 

10 take from an originator 200 to a recipient 204, 208. This route is not 
usually specified in the message, but is determined bv the messaging 
system. The originator 200 creates the message and submits it to the 
messaging system. The message is made persistent localiv. 
The message is then forwarded to the next hop and made persistent 

15 there at the intermediate node 206. This processes of persisting and 
forwarding is repeated between the intermediate node 206 and 
recipient! 208. The message is received by the recipient. At this time, 
the message may or may not persist after this point; however, usually it 
does persist. A copy of the message may similarly be delivered to 

20 Recipientl 204 through some intermediate nodes 202. 

It is important to note that messages persist (i.e., are stored), and 
that they may be forwarded several times before reaching their 
destination. If any of the intermediate links are down, the message is 
held at that hop until the next hop can be reached. This is a basic 

25 description of store and forward messaging, including: 

Store and forward messaging has manv advantages: 

• All of the nodes along the route do not have to be up 
simultaneously. 

• The originator does not need to be directly connected to the recipient. 
30 • Timing is less restricted, so translation at intermediate nodes is more 

feasible, allowing for interconnection of different messaging systems. 

• Messages are held in a persistent state and are therefore more 
immune to failures. 

35 Store and forward messaging also has the following drawbacks: 

• Failures can occur asynchronously with respect to submission context 
forcing more complicated error reporting and status interrogation 
machinerv. 
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Timmg is unpredictable. 

Gateways and translation may result in loss of data fidelity. 
Reception is not guaranteed. 

Error reporting generally uses messaging facilities as well, so error 
notifications mav be lost. 

Retransmission unit is usually the whole message, which can be 
quite iarge. 

Intermediate hops must have persistent storage available. 
Messages are handled by entities who are not the originator and 
recipient, opening a potential security hole in the system. 
Since the connectivity is not direct, originators may need help in 
finding recipients, either by being explicitly told of their existence or 
by browsing some directory. 

In general, messages can carry any data. In practice, as shown in 
FIG. 3, many messaging systems are restricted to carrying a text stream 
from a limited character set. This is a consequence of the fact that many 
messaging systems had their roots in facilities designed to provide 
electronic mail between human users. Electronic mail is still one of the 
20 mam clients of messaging, and many messaging services are in fact 
implemented on the remnants of old e-maii systems. 

As a result of this, messages containing non-text data mav need to 
be encoded when sent using older messaging systems. In addition, the 
capacities of these older maii systems are based on 1960's and 1970's 
2r technology, which may limit the maximum message size (i.e., messages 
larger than this size may be truncated, dropped or bounced back). 

Because of the ability to gateway systems together, the picture of 
the messaging systems of today and the near future may be even more 
complicated. It is possible to join heterogeneous systems in manv 
30 different combinations. This is very common in today's business 

environments. For example, FIG. 4 shows a typical messaging svstem. 
At least three different messaging systems are depicted here. Some are 
directly connected, meaning that some form of gateway exists between 
them and that at least some messages are capable of being routed 
35 between the different systems. An example of this is QuickMail 400 and 
Internet 402. Others are indirectly connected, meaning that they are 
directly connected to the same third system. An example is 
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Compuserve 404 and QuickMaii 400 being indirectly connected through 
Internet 402. 

Several important points to remember about heterogeneous 
environments are: 
5 • Connectivity (direct and especially indirect) of different messaging 
systems may result in loss of data fidelity due to translations and 
transformations. 

• There may be several ways to address a recipient. 

• A single workstation may participate in multiple messaging systems. 
10 . Different systems offer different services and guarantees about those 

services. Requests made of one system may not be honored by 
another. This can happen without the originator's knowledge or 
permission. 

15 The present invention provides an interface or a front end to such a 
messaging system. The interface presented in the following sections 
attempts to provide choices to clients to ensure the level of integrity and 
interoperability desired. The interface achieves the following goals: 

• The interface is protocol independent (e.g., it is not specif ically 
designed for use with only the Internet or some other electronic mail 
system). 

• The interface supports any content type. 

• The interface supports property-based message filtermg. 

• The underlving framework supports multiple messaging protocols. 

• The underlying framework allows implementations of multiple 
messaging protocols to be concurrently active. 



20 



30 



FIG. 5 shows the components of a preferred embodiment 
messaging system architecture. The messaging interface 500 is a set of 
classes that client applications (e.g.. E-mail 502 and Groupware 
Applications 504) use to access messaging features. The messaging 
framework 506 is a set of classes which provide the functionality 
specified by the messaging interface 500. A service provider plugs into 
the framework 506 and provides an implementation for functionality 
3d that is specific to a messaging protocol or a storage structure. Three 

service providers are shown, including: Simple Mail Transfer Protocol 
(SMTP) 508, cc:mail 510, and X.400 512. 
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The messaging interface 500 communicates between a client 
application (e.g.. E-mail 402) and a messaging service for a computer 
system (e.g., a messaging framework 406). An exampie of how this 
messaging interface 500 might be implemented is an OOP-based 
5 environment is shown in FIG. 6. A storage device (e.g., RAM 114, ROM 
116, and / or hard disk 120) stores object oriented programming based 
classes. The basic functions which need to be embodied in classes are 
data members and member functions related to: a message in the 
messaging service, a bin for holding the message, and mechanism for 

10 identifying a message bin. These functions can be stored in one or more 
classes. In this example, each of these functions is in a different class 
(i.e., class 1, class 2, and class 3). A processor 110 retrieves classes from 
the storage device 114 and generates a messaging interface object for the 
message as an instance of the retrieved class. This generated messaging 

15 interlace object alone or in conjunction with other generated objects 

furnishes the client application with protocol independent access to the 
messaging service. By using high-level objects, communications from 
the chent applications can be generalized for any service provider or 
communications protocol. These generalized communications are then 

20 interpreted by the underlying messaging framework and converted to a 
compatible format before sending them to the service provider (e.g., an 
Internet service provider). Similar conversions are done bv the 
messaging framework through the messaging interface in the receiving 
direction so that both directions of communication are seamless to the 

25 ciient applications. 

The following description is focused on the messaging interface 
classes and general design principles used in applying them. 

FIG. 7 shows the class hierarchy for the preferred embodiment 
messaging interface. The class tree consists of many abstract classes 

30 needed to provide clear demarcation of behaviors and concrete classes 
that client applications can directly use. The concrete classes are shown 
with bold and italic text in this and the following figures. 

Appropriate interface classes are multi-thread safe for client 
application's usage, but some classes are not. Later sections will describe 

35 each class in detail and specify whether or not it has thread-safetv. 

Issues of ownership of a heap-allocated object can be quite 
problematic. The messaging interface classes are generallv reference- 
counted, and manipulation of objects is through the safe-pointer objects 
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to memory locations. This design frees messaging client applications 
from the responsibility of storage-deallocation and thus is considered 
memory safe. 

The messaging interface has many classes that act on behalf of a 
real object - in some cases persistent objects (e.g., messages, message 
boxes, etc.). The later sections will identify these classes as surrogate 
classes. The classes that stand for themselves are labeled value-like. 
One important difference a client application might notice between 
surrogate and value-like classes is that an operation on a surrogate 
object may fail due to the demise of the real object backing it. For 
example, the command "get subject" operation on a message object will 
fail, if the message object instance it is referring to has been deleted. 

The objects in TMessage hierarchy are thin handles with hidden 
master objects behind them. Hence these objects are cheap to copy. 
15 Different classes in TMessage 724 hierarchy represent a message at 

different stage in its life-cycle through the messaging svstem. 
TDraftMessage 726 part of the tree represents the messages in 
construction. These messages are not yet submitted for the delivery and 
allow adding data and messaging attributes to them. 
20 TMessageReference 712 on the other hand represent a message that has 
been either submitted or received and hence immutable. FIG. 8 shows 
the life-cycle of a message. Also, since message classes other than 
TMessageReference 712 are used for construction only, they can not be 
copied. This means that only one copy of a particular draft message 
25 exists at a time thus avoiding conflicting access to same message. 

The basic concept and behavior for all the interface classes of the 
preferred embodiment are described in the following section. A simple 
basic attributes table is provided for every class. This table provides a 
quick way to find out about many basic attributes of a class. A 
30 description of these basic attributes is given in Table 1 below. 

Table 1 

ir Muln-thread-safe An instance of this class can be concurrently accessed bv 

• > - > more than one thread. 

Multi-instance-sare Multiple instances of this surrogate class can be 

concurrently used to access the real object. 



40 Static-safe 



It is OK to construct an instance of this class at static 
construcnon nme. 
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^narea-memorv-sare 

Surrogate Value 

Allows inheritance 

Allocation 

Abstract /'Concrete 
5cope or uniqueness 
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It is OK to keep an instance or this ciass in shared- 
memory 

Describes whether an instance or this ciass is a 
surrogate tor some otner object. 

An instance or this ciass can be subclassed. Some classes 
are designed to be used monomorphicaliv. 

Describes whether this class allows creanon or 
instances on the stack or heap or both. 

Describes whether tms ciass allows creanon or objects. 

Provided onlv ror idennher classes, it derines the name- 
space within wrticn the idennher is uruoue. 



Incidental system functions like assignment operator, copy constructor, 
and streaming operators. 

2° The messaging system needs to keep messages in some storage 

device (e.g., a magnetic or opticai disk drive, a RAM, or a floppv disk). 
message bin classes provide abstractions ror different kinds of message 
storage. A message is always associated with a message bin. FIG. 9 is a 
block diagram of the class hierarchy for the preferred embodiment 

25 message bin classes. 

The root of the hierarchy is an abstract mixin class, message bin 
class 700, which represents a message bin of any kind. An example of 
this class is implemented in the preferred embodiment as the 
MMessageBin ciass 700 and could be implemented in anv other generic 

30 message bin class. There are two main kinds of bins. First, there are 

bins that allow storing messages into them. Second, there are bins that 
allow retrieving messages from them. The former is represented bv the 
message store mixin class 702 and the latter is represented bv the 
message source mixin class 704. An example of these classes are 

35 implemented in the preferred embodiment as the MMessageStore class 
702 and MMessageSource class 704. Each of these could be implemented 
in any other generic message store class and message source class, 
respectively. Concrete subclasses that allow both storage and retrieval of 
messages will inherit from both mixins. The preferred embodiment 

40 messaging system provides such concrete classes. 

The message sender class provides the functionality for message 
submission and sending. An example of this class is implemented in 
the preferred embodiment as the MMessageSender class 706 and could 
be implemented in any other generic message sender class. A sender 

45 always needs a store to keep the submitted messages. In the preferred 
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~men, to simpiifv client applications usage, a MMessageSender 

Vl u * " We,L S,milariv ' receiVer functionality is 

provided by message receiver class 708 for receiving messages at a ' 

reefer-address. An example ot this class is implemented in the 
o preferred embodiment as the MMessageReceiver class 708 and could be 
implemented an any other generic message receiver class. It also is a 
MMessageSource 704 so that client applications can retrieve messages 
directly from it. & 

The MMessageBm class 700 is the root of the bin class hierarchy 
10 It defines a protocol that all bin classes must support as noted in Table 
below. ~ 
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Multi-thread-sare 


Yes 


Surrogate/ Vaiue-iike 




Multi-insrance-sare 


Yes 


_AHows inheritance 


Yes 


Static-sate 


No 


Atlocatior, - stack.hean 




Shared -memorv-sa re 


\ : o 




Heap 



MRet erenceCoun ted 

Constants, Enumerators. Types: 

• enum 

EStatus IkAvailab.'e. kUnavailablel 

Memoer Funcnons: 

• virtual EStatus 
uerStatus () = 0 

• virtual boo! 

Contains iconst TNlessaeeReterenceo* message] 

• virtual bool 
DeleteAll 0=0 

• virtual TCuuntedPouiterTo<TMessapeBinNamc> 
GetNameO = 0 



JO 



40 



The enumerator Estatus reflects the status of a bin. In particular a 
bin may be currently unavailable (e.g., the network connection mav be 
broken). A message bin will attempt ^connection upon a function-call 
if it is unavailable. One status is "kAvailable" which means that a 
message bin is currently accessible. Another status is '^Unavailable" 
which means that a message bin is currently inaccessible. 

The GetStatus function returns the status of this bin. If the 
returned value is kUnavailable, the bin is currently inaccessible. If the 
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bin is unavailable and tryReconnectlflJnavailable is true, this call wiil 
attempt reconnection before returning the status. 

The Contains function returns a true value, if the specified 
message itself is contained within the storage represented bv the bin. 
5 Tne DeleteAll function deletes all messages in this bin. After 

successful completion, this function will leave the bin emptv. A 
successful completion is indicated by the returned value of true. This 
function will not delete a message that is currentlv being accessed. In 
that case, it returns a false value after deleting all other messages. 
10 The GetName function returns the message bin name for this 

bin. 

The MMessageSource class 704 is a subclass of MMessageBin 700 
that adds message retrieval protocol as noted in Table 3 below. 



15 Table 3 



Basic Attributes: 



Multi-thread-safe 


Ye:> 


Surroeate/ Value-like 


Surroeate 


Multi-mstance-sare 


Yes 


Allows inheritance 


Yes 


Static-sate 


No 


Allocanon - stack. heap 


Heao 


Sha red -memorv-sa re 


Mr 


Abstract/Concrete 


Abstract 



Inherits From: 
MMessageBin 



Member Funcnons: 

• virtual TMessageReterence 

GetAllMessages lTCoUectionOf<T\lessaeeReference> Ac 
returned Messages > const = v x 

—3 • virruai unsigned lone 

GetxVtessaeeCounti i const =0 

• virtual TMessageReference 

VVaitForMessaeeArter tconst TMessageReterence&c starttn^Point) = o 

• virtual TOnlyPo»nterTo<:TMessac:eIterator> 
30 Createiterator () const 

The GetAllMessages function adds the message references of all 
the messages in this bin to the supplied collection. Previous contents of 
the collection are left unchanged. 
35 The GetMessageCount function returns the number of messages 

contained in this bin. 

The WaitForMessageAfter function blocks the calling thread 
until this bin has a message whose LocalCreateTime is later than the 
LocalCreateTime of startingPoint. If an invalid TMessageReference is 
40 passed then the starting LocalCreateTime is assumed to be 
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TTime::kNegativelnrinity. and the nrst message in the bin will be 
returned. 

The Createlterator creates an instance of the message iterator class 
710 to iterate over the messages in this bin. An example or this class is 
5 implemented in the preferred embodiment as the TMessagelterator 
ciass 710 and could be implemented in any other generic message 
iterator class. 

The TMessagelterator class 710 provides iteration functionality 
over a collection of messages, primarily a message source as noted in 
10 Table 4 below. 



15 



20 



Basic Atrnbu res : 



Table 4 



Multi-thread-sare 


No 


Surrocate/ Value-tike 


Value-like 


Multi-msrance-sare 


Ves 


Allows inheritance 


\es \ 


Stauc-sare 


No 


Allocation - stack. heap 


Heao 


Shared-memorv-sare 


No 


Absrract /Concrete 


Abstract 



Inherits From: 
None 

Member Functions: 

• virtual TMessageReference 
First i ) = 0 

• v irrua! TMessageReference 
Next 0 = 0 

• virtual TMessageReterence 
Get Most Recent () const = 0 



30 



35 



The First function returns the first message in this bin. If the bin 
is empty, an invalid TMessageReference object is returned. 

The Next function returns the next message in this bin. If the bin 
is empty, an invalid TMessageReference object is returned. 

The GetMostRecent function returns the most recent 
TMessageReference returned by either the First or Next function. If the 
bin is empty or no calls to First or Next function have been made, an 
invalid TMessageReference object is returned. 

The MMessageReceiver class 708 is a subclass of MMessageSource 
class 704 that can receive messages and adds protocols to get its address 
as noted in Tabie 5 below. 
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Table 5 



Basic Attributes 



Multi- thread -safe 


Yes 


surroeate /Vaiue-hke 


Surroeate 


Multi-mstance-sare 


Yes 


Allows inheritance 


Yes 


Stanc-sare 


No 


Allocation - stack. hean 


Heao 


Sh a red -memorv - sa re 


No 


Abstract / Concrete 


Abstract 



Inherits From: 
D MMessaeeSource 

Member Funcnons: 

• virtual TCountedPointerTo<TMes$aeeReceiver Address> 
GetName t ) = 0 

10 

The GetAddress function returns the address for this receiver. It 
may be used to send messages to this receiver. 

The MMessageStore class 702 is a subclass of MMessageBin class 
700 and adds message storing protocol as noted in Table 6 below. 

15 

Table 6 



Basic At tnbu tes: 



Muln-rhread-sate 


Yes 


Surroeate/ Value-like 


Surroeate ! 


Multi-instance-sate 


Yes 


Allows inheritance 


Yes 


Static-sate 


No 


Allocation - stack.heaD 


HeaD 


Shared -memorv-safe 


No 


Abstract / Concrete 


Abstract 



inherits From: 
20 MMessageBin 

Member Functions: 
• virtual TMessageReterence 
^_ Copylnto i const TMessaeeReterenceac messaeeReference. 

boo! allow Duplicates = raise i 

The Copylnto function copies the specified message into this bin. 
If the message is contained in this bin, another copv is made if 
allowDupiicates is true. It returns a reference to the new message. If the 
30 message is contained in this bin and allowDupiicates is false, then an 
invalid reference is returned. 

The MMessageSender class 706 is a subclass of MMessageStore 
class 702 and adds protocol for sending messages as noted in Table 7 
below. 

35 
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Multi-thread-sare 


Yes 


Surroeate/VaJue-Jike 


Surroeate 


Multi-instance-sate 


Yes 


Allows inheritance 


Yes 


Static-sare 


No 


Allocanon - stack. heao 


m Heap 


Sha red -mennorv-sa re 


No 


Abstract/Concrete 


Abstract 



inhents From: 

MMessageStore 

Member Funcnons: 

• virtual TMessaeeRererence 

Submit iconst f Drart.Messageec message) = 0 

♦ static TCountedPointerTo<MMessa?e5ender> 
GetDerauJtSender () = 0 



15 



20 



25 



30 



The Submit function submits a message in draft state tor deliver- 
to its recipients. After this call, the message is no longer a draft message. 
The draft message, passed in as a parameter, is invalidated and a 
message reference object instantiated from a message reference class 712 
which points to the submitted message is returned. An example of this 
class is implemented in the preferred embodiment as the 
TMessageReference class 712 and could be implemented in any other 
generic message reference class. 

The GetDefaultSender function returns the default 
MMessageSender. It is primarily used to submit messages. 

The file system message store class 714 is a concrete subclass of 
MMessageSender class 706 (which is a subclass of MMessageStore class 
702) and a subclass of MMessageSource class 704. It represents a file- 
system-based message bin. Messages are stored in a file svstem directory. 
It provides functionality for storing, accessing and sending messages as 
noted in Table 8 below. An example of this class is implemented in the 
preferred embodiment as the TFileSystemMessageStore class 714 and 
could be implemented in any other generic file system message store 
class. 
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Table S 



Basic Attributes 



Multi-thread-sate 


Yes 


5 u r r o ea t e / V" a 1 u e- 1 1 ke 


Surroeate 


Muiti-insrance-sare 


Yes 


Allows inheritance 


Yes 


Static-sare 


No 


Allocation - stack. heap 


Hean 


Shared - memorv-sar e 


No 


Abstract /Concrete 


Concrete 



Inherits From: 

MMessaeeSender 
MMessaeeSource 



Member Functions: 
I T Directory 

GetDirectorv () const 
i bool 

DeieteSelf () 



The GetDirectory function returns the directory used for message 
15 storage, 
bool 

The DeieteSelf function deletes all messages in this bin and, if 
successful, deletes the bin itself. A successful completion is indicated bv 
the returned value of true. This function will not delete a message that 

20 is currently being accessed — in that case it returns false after deleting 
all other messages and the bin remains intact. If successful, subsequent 
calls to GetStatus will return kUnavailable — all other calls will result 
in a TMessageBinUnavailable exception being thrown. 

Accessing a specific instance of a message bin requires that the 

25 client be able to specify that bin. This is accomplished using a bin name. 
Once a bin name is obtained or constructed, a bin can be obtained using 
the bin name. Bin names are also used to address messages. 

The message bin name class 716 and all subclasses, shown in FIG. 
10, must be displayable everywhere. An example of this class is 

30 implemented in the preferred embodiment as the TMessageBinName 
class 716 and could be implemented in any other generic message bin 
name class. The protocol for display name is handled by the base class. 
In addition, they must be transportable everywhere. The default storage 
and streaming behavior is managed by the base class to ensure that 

35 slicing never occurs. 

An instance of the TMessageBinName class 716 identifies a 
message bin. Its primary purpose is to allow a client to access a message 
bin. A TMessageBinName class 716 supports the GetPresentationName 
and GetTextPresentation functions. The TMessageBinName class 716 
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does not slice so that all or the data of the original class as well as the 
type is preserved as noted in Table 9 beiow. 



Basic Attributes: 




Table 9 


Muhi-thread-safe 


Yes 


Surroeate/ Value-like 


Value-like 


Muhi-mstance-sare 


n /a 


Aliows inheritance 


Yes 


Static-safe 


No 


Allocation - stack.heaD 


Heao 


Shared-rr.emorv-sare 


No 


A bs t r a c t / C one re re 


Concrete 






Scone or uruoueness 


Global 



Inherits From: 

VtRererenceCounted 



10 Member Functions: 

• TCountedPomterTo< M MessaeeBin> 
GetBin 0 const 

• void 

GetPresentationName iTTextfir fillini const 
15 • void 

GetTextRepresentation i'TText<k fillinoy Appending! const 

The GetBin function returns a counted pointer to the message 
bin. If the TMessageBinName class 716 is invalid, or the class librarv for 
20 the specified bin is not available, an exception is thrown. 

The GetPresentationName function returns the presentation 
name of the message bin. The presentation name is that which would 
be used when displaying the name of the bin to the user. 

The GetTextRepresentation function returns a text representation 
25 of the message bin name. Many message bins have a valid text 

representation for the bin name. This text representation is usually- 
sufficient to fully specify the bin. 

An instance of the file system message store name class 714 
identifies a file system message store as noted in Table 10 below. An 
30 example of this class is implemented in the preferred embodiment as 
the TFileSystemMessageStoreName class 714 and could be 
implemented in any other generic file system message store name class. 
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Table TO 



Multi-thread-safe 


Yes 


Surroeate/ Value-like 


Value-like 


Multi-instance-sare 


r. / a 


Allows inheritance 


Yes 


Static-sare 


No 


Allocation - stack. heao 


Heao 


Shared-memorv-sare 


No 


Abstract /Concrete 


Concrete 






Scooe or uruaueness 


Global 



Inherits From: 

TMessaeeBinName 

Member Functions: 

TrileSvstemMessaeeStoreNarrie iconst TDirectorvAc directory 

• TCountedPointerTo<TFile5ysr«;rruVlessa^eStore> 
GerStore ( ) const 

• TDirectory 
GetDirectory () const 

The TFileSystemMessageStoreName function constructs a file 
svstem message store over a directory. This call throws an exception if 
the directory is invalid. 

The GetStore function returns a counted pointer to a file svstem 

store. 

The GetDirectory function returns a directory used for messages 
storage. 

An instance of the TMessageReceiverAddress (also known as 
MessageReceiverAddress) class 718 identifies a message receiver. Its 
primary purpose is to allow a client to access a message receiver and for 
constructing a message address bundles 720 from its class tor sending 
messages as noted in Table 11 below. .An example of this class is 
implemented in the preferred embodiment as the 
TMessageAddressBundle class 720 and could be implemented in anv 
other generic message address bundle class. 
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15 



20 



Basic Attributes 




Multi-rhreaci-sare 


Yes 


! Surrocnte/Vaiue-like 


Value-like 


Multi-instance-sare 


n / a 


1 Allows inheritance 


Yes 


Static-sate 


No 


Allocation - stack. heap 


Heap 


Shared -memorv-sa re 


No 


Abstract/Concrete 


Concrete 






Scope of uniqueness 


Global 



TMessaeeBirtName 
Member Functions: 

• virtual TCountedPomterTo<MMessaqeReceiver> 
CjetMessageReceiver i ) const 

The GetMessageReceiver function returns a counted pointer to a 
message receiver. It throws an exception, if the receiver cannot be 
constructed, or if an instance of TMessageReceiver Address class 718 is 
invaiid. 

Particular service provider classes can be subclassed rrom any of 
these previously described classes to further enhance the functionality 
of the messaging interface 400. For example, a Internet receiver address 
class 722 can be generated by-inheriting functionality from the 
TMessageReceiverAddress class 718 to add Internet addressing 
capabilities. An example of this class is implemented in the preferred 
embodiment as the TInternetReceiverAddress class 722 and could be 
implemented in any other generic internet receiver address class. 
Similarly, classes can be generated for other messaging svstems such as 
X.400. 

An instance of the TInternetReceiverAddress class 722 identifies 
an RFC-S22 compliant mailbox address as noted in Table 12 below. 
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35 
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Table 12 



Multi-thread-sare 


No 


Surrocate/ Value-like 


Value-like 


Multi-msrance-sate 


n,* a 


Allows inheritance 


Yes 


Static-sare 


No 


Allocation - stack.heac 




Sha red - memo rv-sa r" e 


No 


_ Abstract/Concrete 


Concrete 






Scope or uniqueness 


Global 



Inherits From: 

TMessaeeRecesver Address 

Member Functions: 

TInterr.etReceiverAddress iconst TTexti RFC-S22address) 

Tlnterr^RrceiverAddress ,const TText& userName. const TText& 
nosLName. const TTexU* DresentanonName = 
TStandarc iext::GetEmpryText()) 



void 



OetPar-s :TTexti locaiPart.TTexti: domainParti 



const 



The TInternetReceiverAddress function constructs a 
TInternetReceiverAddress from an RFC-822 conformant string. This 
will throw an exception, if the passed string is not a valid RPC-822 
address. 

The TInternetReceiverAddress function constructs an Internet 
address from components that can be used to form a RFC-822 
conformant string. 

The GetParts function returns local and domain parts of the RFC- 
822 address. For a more detailed discussion of the Internet messaging 
standard and the syntax of an RFC-822 Internet address, see Request For 
Comments 822 (RFC-822) by Dave Crocker dated August 13, 1982. 

A message class 724 represents a message. An example of this 
class is implemented in the preferred embodiment as the TMessage 
class 724 and could be implemented in any other generic message class. 
There are many kinds of messages in a messaging system. For example, 
some kinds are messages received at an address, messages sent from an 
address, and messages in construction yet to be sent. 

Various subclasses of the TMessage class 724 represent different 
kinds of messages as shown in FIG. 11. The TMessage class 724 has the 
basic functionality for all of them as noted in Table 13. 
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Table U 



Basic Attnbu tes * 



Vlulti-:nread-sare 


No 


Surroeate/ Value- iike 


Vaiue-iike 


Multi-instance-sate 


n/a 


Allows inheritance 


Yes 


Static-sate 


No 


Allocation - stack. hear 


HeaD 


Shared-memorv-sate 


No 


Abstract /Concrete 


Concrete 



Inhents From: 
None 



Constants. Enumerators. Types. 

• Componentlndex kinvalidlndex 
An invalid Componentlndex. 

10 • enum 

EStarus ikDrart. kPending. kSending. 
kSent. kKeceived. kFariedi 

• enum 

Elmportance ikBulk, kNormai. klmportanti 
I 3 • enum 

FSrreamFormat IkMonomorpruc. kPolv.Vlorphici 

MemDer Funcnons: 

• booi 

20 IsValid 0 const 

• bool 

opera tor== i const TMessage&c message; const 

• booi 

operators (const TMessage&c message; const 
25 • booi 

operator > iconst TMessage& message; const 

• boo) 

operator < iconst TMessage& message) const 
bool 

30 operator >= (const TMessaeea: message; const 

• bool 

operator <= iconst TMessaeeoc message; const 

• HashResult 
Hash :; const 

-"O • booi 

IsContainedln (const MMessageBinfc messageBln; const 

• unsigned long 

CountAddresses {TMessageAddressBundle::Kjnd5et hlten const 

• Componentlndex 

40 CouricComponents () const 

• Componentlndex 

DoesContainType (const TType5urrogate& component Type) const 

• bool 

_ IsComponentTvpe (const TTypeSurrogateSc component Type, 

43 Componentlndex index) const 

• void 

GerComponentType (TTypeSurrogate& hllin. 
Componentlndex inaex ; const 

• ESrreamrormat 

^0 GeKZomponencStreamForTnat (Componentlndex index ; const 

• void 

GetSubiect (TText& fillin) const 

• EStatus 
GetStarus I) const 

33 • Elmportance 

Getlmportance () const 
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• TTirr.e 
GetCreateTirr.e i ) const 

• TTLme 
GetLocaiCreareTtme 1 1 const 

• TCountedPointer i o<MMessaeeBin> 
GetBin < • const 

• void 
DeleteSelr 0 const 



10 The EStatus enumerator reflects the status of a message. The 

message may have a status of many different types. For example, 
"kDraft" means that an instance of the TMessage class 724 has not vet 
been submitted for delivery. All newly created messages are in this state 
and remain in this state until the client application calls Submit or Send 

15 on it. Another status is "kPending" which means that an instance of 
the TMessage class 724 was submitted by the client application for 
delivery but the messaging system has not yet sent it to a messaging 
server. Another status is "kSending" which means that an instance of 
the TMessage class 724 is currently being sent to a messaging server. 

20 Another status is "kSent" which means that an instance of the 

TMessage class 724 was successfully sent to a messaging server. Another 
status is "kReceived" which means that an instance of the TMessage 
class 724 was received by the messaging system. Another status is 
"kFailed" which means that an instance of the TMessage class 724 could 

23 not be delivered. 

The Elmporrance enumerator has manv values, including: 
"kBulk". "kNormai", and "krnportant". Each is an indication of the 
client application's assessment of the importance of this message. 
"kBulk" is the least important and "klmportant" is the most. This tag 

30 (enumerator) is mutually interpreted by the messaging client 

applications, because it is not interpreted by the messaging svstem. 

The EStreamFormat enumerator preferably has two values. One 
value is "kMonomorphic", which indicates that an instance of the 
TMessage class 724 was added using the AppendMonomorphic 

35 function, and must be retrieved using GetMonomorpic function, 

Another value is "kPolymorphic", which indicates that an instance of 
the TMessage class 724 was added using the AppendPolvmorphic 
function, and must be retrieved using the GetPolvmorphic function. 

The IsValid function checks if an instance of this class is a valid 

40 message. A message created using an empty constructor and a message 
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rererence returned at the end of an iteration are invalid references. It 
returns a true, if the message is valid. Most operations on an invalid 
message will fail. Operations on a valid reference might still fail, if the 
message has been deleted or otherwise unavailable for access. 
5 The operator== and operator'^ functions check for equalitv and 

inequality, respectively, between two messages. The first returns a true 
and the second returns a false, respectively, oniy if both references refer 
to the same message. The other operator functions perform an ordered 
comparison check for Uvo messages. Message order is based on the 
10 LocaiCreateTime. 

The Hash function returns a hash key for this message. 
The IsContainedln function returns a true if this message is from 
the storage represented by messageBin. 

The CountAddress function returns the number of address in 
15 this message whose kind matches filter. 

The CountComponents function returns the number of 
components in this message. The DoesContamType function 
returns the index of the first component of type described by 
componentType. It returns klnvaldlndex, if no matching type is found. 
The IsComponentType function returns a true if the component at 
specified index is of type described by componentType. The 
GetComponentType function returns the type of component at specified 
index in fillin. The GetComponentStreamFormat function returns the 
streaming format for component at specified index in fillin. 

The GetSubject function assigns the subject for this message to 
fillin. The GetStatus function returns the status of this message. The 
Getlmportance function returns the importance tag for this message. 
The GetCreateTime function returns the time in UTC (Universal 
Coordinated Time) when this message was created. The 
GetLocalCreateTime function returns the time in UTC (Universal 
Coordinated Time) when this message was created in the current bin. 
Will == create time unless this message was copied from another bin 
(see MMessageStore::Copyinto) in which case it is guaranteed to be > = 
create time. The GetBin function returns a counted pointer to the 
35 message bin that contains this message. 

The DeleteSelf function deletes the message referenced by this 
object. The DeleteSelf function may fail if the message is a draft 
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message and is currently being accessed. Failure typically is indicated bv 
an exception. 

The TMessageReferenco class 712 is a subclass of the TMessage 
class 724. It represents either a received or submitted message. A 
message of this kind can not be modified as noted in Table 14 below. 



10 



15 



20 



Basic Attributes: 



Multi-thread-sare 


No 


Surroeate/Vaiue-like 


Surroeate 


Multi-instance-sare 


Yes 


Allows inheritance 


Yes 


Stanc-sare 


No 


Allocation - stack. heap 


Bith 


Shared -memorv-sate 


No 


Abstract /Concrete 


Concrete 



Inhents From: 
TMessage 

Constants. Enumerators. Tvpes: 

• enum 

Einteqnrv Iklntact. kDoNotKnow* 

Member Functions: 

• TTime 
GetSubmitTime ( ) const 

• TTime 

, GetReceiveTime {) const 

• EIntegnty 
Getinteenry () const 

• TSTream<& 

operator>>= fTSrreamck toWherei const 

• T5Tream& 

operator<<= (T5trenm<i: from Where) 



30 



35 



40 



The enumerator Elntegnty can have a "klntact" value, which 
means that an instance of the TMessage class 724 was received without 
any loss of data. Alternatively, a "kDoNotKnow" status means that an 
instance of the TMessage class 724 does not have enough information to 
judge its integrity. 

The GetSubmitTime function returns the time in UTC 
(Universal Coordinated Time) when this message was submitted for 
delivery. The GetReceiveTime function returns the time in UTC when 
this message was received. If the message status is not Kreived, then 
the message has never been received (probably because it is an outgoing 
message) and the time returned is TTime::kPositiveInfinitv. 

The Getlntegrity function returns the integrity with which this 
message was received. 
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The operator>> = and operator<<= runctions streams this 
message reference and not the message data to and from, respectively, a 
stream. 

The TMessage class 724 is generally useful for referring to any 
5 kind of a message and accessing the message data. It does not provide a 
protocol for the creation and addition of data, because not all messages 
support that behavior. For example, received messages are immutable. 
The draft message class 726 and its subclasses provide functionality for 
constructing a new message, writing data to it and sending it. An 
10 example of this class is implemented in the preferred embodiment as 
the TDraftMessage class 726 and could be implemented in any other 
generic draft message class. 

A message sent from an OOP-based messaging system mav travel 
through a series of messaging routers (most of which will be non-OOP- 
15 based for quite some time). A recipient for the message may be a non- 
OOP-based messaging system. In such an environment, the issues of 
integrity of a message through the delivery and its interoperabilitv with 
non-OOP-based systems needs to be clearly defined. Several subclasses 
of the TDraftMessage class 726 may be defined to support different trade- 
20 offs between data-integrity and interoperability. 

For example, the OOP-specific message class 728 guarantees the 
data-integrity when delivered to a recipient. An example of this class is 
implemented in the preferred embodiment as the 
TCommonPointMessage class 728 and could be implemented in any 
25 other generic message class. However, only an OOP-based messaging 
system (e.g., a CommonPoint™ messaging system) will be able to 
retrieve the data from an instance of the TCommonPointMessage class 
728. CommonPoint™ is a trademark of Taligent, Inc. In contrast, the 
interoperable message class 730 is interpretable by and can be sent to a 
non-OOP-based messaging system. It, however, does not guarantee data 
integrity. In particular, an instance of the interoperable message class 
730 may have undergone lossy transformation of message contents. An 
example of this class is implemented in the preferred embodiment as 
the TInterOperableMessage class 730 and could be implemented in anv 
other generic interoperable message class. 

A CommonPoint™ messaging system client application will 
choose a kind of draft message based on the requirements for data 
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integnty and interoperability dictated bv the problem domain as noted 
in Table 13. 



Table 15 

5 Basic Attributes. 



Mulh -thread -safe 


No 


Surrogate/ Value-like 


Surrocare 


Multi-instance-sate 


Yes 


Allows inheritance 


Yes 


Staftc-sare 


No 


Allocation - stack.heao 


Both 


Shared-memorv-sare 


No 


Abstract /Concrete 


Abstract 



Inherits From: 

TMessageReference 

10 Constants. Enumerators. Types: 

• enum 
ERepIvRecipientHandling 

fkReplyToSenderOnlv.kReplyToAURecioientsI 

• enum 

1 ? ECopyRecipientHandline I'kCopvNoRecipients.kCoDvAIIRecioientsf 

• enum 

ESubiectHandiinp IkDoNotCopySubiect. kCopvSubiectj 

• enum 

EComponentHandhr.g IkCopyKoCorr.ponents. kCopyAiJComponentsi 

Member Functions: 

• void 

Append Address (const TMessageAddress Bundled bundle) 

• void 

2.2 AppendAddress (const TCounted Poi n te rTo<TMess ace Receiver A ddress> &r 

address. TMessageAddressBundle::ERind = T&essageAddressBundle::kTo) 

• void 

AppendComponent (const TMessageReterence&r rrom Where. 
Componentlndex index) 

30 

The following enumerators control message creation behavior, ■ 
when a draft message is created as a reply, forward, or copv of an existing 
message. 

The enumerator ERepIvRecipientHandling controls recipient 
35 handling when creating a draft message as a reply o a message. It may 
have a "kReplyToSenderOnly" value which uses the sender of the 
original message as a recipient. Alternatively, it may have a 
"kReplyToAHRecipients" value which uses all of the recipients of the 
original message as recipients. 
40 The enumerator ECopyRecipientHandling controls recipient 

handling when creating a draft message as a copy of a message. It may 
have a "kCopyNoRecipients" value which does not copy any recipients 
from the existing message. Alternatively, it may have a 



SUBSTITUTE SHEET (RULE 26) 



W ° 97/22928 PCT/US96/20536 



10 



20 



•34- 



'kCopyAURecipients" value which cop.es ai! recipients from the 
existing message. 

The enumerator ESubjectHandiing controls the subject handling 
when creating a draft message as a forward, reply or copv of a message 
It may have a "KDoNotCopySubject" which indicates that the subject of 
the original message is not to be copied to this message. Alternatively 
it may have a "kCopySubject" value which indicates that the subject of 
the original message may be copied to this message. 

The enumerator EComponentHandling controls the component 
handling when creating a draft message as a forward, replv or copy of a 
message. It may have a "kCopyNoComponents" value which indicates 
that none of the components of the original message are to be copied to 
this message. Alternatively, it may have a "kCopvAHComponents" 
value which indicates that the components of the original message mav 
be copied to this message. 

The function AppendAddressBundle adds an address bundle to 
the list or addresses tor this draft message. It may also add an address 
bundle with the specified address and kind to the list or addresses for 
this draft message. 

The function AppendComponent copies component at index in 
message fromWhere to next index in this message and returns an 
address to the iist of addresses for this draft message. 

The TCommonPointMessage class 728 is a concrete subclass of 
TDraftMessage class 726. This message supports multiple components 
or anv data-tvpe and styled-text as subject. It does not translate the data 
from its original form to any other as noted in Table 16. 
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Table 16 



Basic Attributes: 



Multi-thread-safe 


Ko 


?urrocate / Value- like 


Surroeate 


Multi-:nstance-sare 


Yes 


Allows inheritance 


Yes 


Static-sate 


N : o 


Allocation - stack. heaD 


Both 


Shared-memorv-sate 


No 


Abstract /Concrete 


Concrete 



inherits From: 
TDr3tt Message 



Member runcnons: 

TCornmonPointMessage iconst TTextic subject ► 

10 TCommonPointMessase (const TText& subject, const 

TCountedPomterTo<TMessaeeRece!verAddress>(ic to Address) 

• static TCornmonPointMessage 

Forward (const TMessaReRef(-*rence& sourceMessa^e, 
1 5 EComponentHanclling componentHandlin^. ESubiectHandling 

subjectHandlinc. const TText<k prependToSubiect = 
T5tandardText::GetEmpcyTexU)) 

• static TCornmonPointMessage 

Reply iconst TMessaeeReferencee* sourceMessa^e, 
20 ERepiyRecipientHandhne rec:pienrHandhng, 

EComponeiit Handling componentHandime. ESubiectHandling 
subiectHandling, const TText&c prependTo5ub)ect = 
TStandardText::GetEmnrvTexti*)) 

• stanc TCornmonPointMessage 

25 ^°pv Konst TMessaceSt sourceMessaee, ECopyRecipientHandling 

recipient Handing. EComponent Handling componentH and ling, 
ESubiectHandiing subiectHandling. const TText& 
prependToSubiect = TSlanaardText::GetEmpryTextO) 



30 The function TCornmonPointMessage allows client applications 

to create new CommonPoint™ messages with a specified subject. One 
of the constructors allows specifying an address to which this message 
should be sent. 

The function Forward creates a CommonPoint™ message as a 
35 forward of the specified message. The newly created CommonPoint™ 
message is properly formatted as a forwarded message. Parameters 
componentHandling and subjectHandling provide clients a finer 
control of controlling various properties of the created message as 
described earlier. If prependToSubject is present, the specified text is 
40 prepended to the subject of sourceMessage to create subject for the 
returned message. 

The function Reply creates a simple message as a reply to the 
specified message. The newly created simple message is properly 
formatted as a reply message. Parameters are handled in manner 
45 similar to Forward function. 
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The function Copy creates a simple message as n copv of the 
specified message. Parameters are handled in manner similar to 
Forward function. 

The TInterOperableMessage class 730 is a concrete subciass of the 
TDraftMessage class 724. This message supports multiple components 
of any data-type and unstyled-text as subject. Upon transmission, it may 
translate the data from its original form to one appropriate for passage 
through the messaging system. Such a translation mav incur loss of 
information from the data as noted in Table 17 below. 



Basic Attribu tes: 



Table 17 



Multi-thread-sare 


No 


Surroeate/ Value- like 


Surroeate 


Multi-instance-sace 


Yes 


Allows inheritance 


Yes 


Static-sare 


Nio 


Allocation - stack. heap 


Both 


Sha red-memo rv-sate 


No 


Abstract /Concrete 


Concrete 



Inherits From: 

TDraftMessage 

VI ember Functions: 

TInterOperableMessage (const TText& subject) 

TInterOperableMessage (const TText& subject, const 

TCountedPointerTo<TMessageReceiverAddress>6: toAddress) 

TInterOperableMessage (const TTexteSc subject, const 

TCountedPointerTo<TMessat;eReceiverAddress> toAddress. const 
TStandardText<k hrstComponent) 

• >tatic TInterOperableMessage 

Forward :const TMessaeeReferencear sourceMessace. 

EComponentHandhne componentHandlmc. ESubiectHandlinc 
subiectHar.diing. const TTextfit prepend ToSubiecc - 
T5tanaardText::GetErnptyText()) 

• static TInterOperableMessage 

Reply (const TMessageReterencefc sourceMessage. 
EReplyRecipientHandiing recipientHandhne, 
EComponentHandhng componentHand ling. ^ESubiectH and ling 
subiectHandltng, const TText& prependToSubject = 
TStandardText::GetEmptyText( )) 

• static TInterOperableMessage 

Copy (const TMessaeei sourceMessage, ERecipientHandiing 

reciDientHandling, ECopvComponentHandhng component Hand line, 
ESubiectHandiing subjectHandlmg, const TText& 
prependToSubject = TStandardText::GetEmptvText(» 



45 



The function TInterOperableMessage allow client applications to 
create new interoperable messages with specified subject. One of the 
constructors allows specifying an address to which this message should 
be sent. Another constructor supports the (monomorphic) addition of a 
single text component. Regardless of which constructor is used so that 
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client appiications can add additional components using the 
AppendMonomorphic and AppendPolymorphic functions. 

The function forward creates a CommonPoint™ message as a 
forward of the specified message (sourceMessage). The newlv created 
CommonPoint™ message is properly formatted as a forwarded 
message. Parameters componentHandling and subjectHandling 
provide client applications a finer control of controlling various 
properties of the created message as described earlier. If 
prependToSubject is present, the specified text is prepended to the 
subject or sourceMessage to create subject for the returned message. 

Tne function Reply creates a simple message as a replv to the 
specified message. The newly created simple message is properly 
formatted as a reply message. Parameters are handled in manner 
simiiar to Forward function. 
1? The function Copy creates a simple message as a copv of the 

specified message. Parameters are handled in manner similar to 
Forward function. 

A component inside a TDraftMessage class 726 can be any 
CommonPoint 1M object. Functionality of writing a component to a 
message and reading one from it is provided in a type-safe wav by 
template functions Add and Get. Conceptualiv, the components in a 
message form an indexed collection. Client applications can add 
components to a message sequentially and access a component using an 
index. Some of these functions are detailed in Table 18 below. 

• —» 

Table IS 

Functions. 

• template <ciass ATvpe> Componentlndex 

Append Pol vmorpruc (TDrattMessa^edr message, const ATvpe<ir component; 
30 • template <class ATvpe> Componentlndex 

AppendMonomorphic (TDrartMessage<k message, const AType& component) 

• template <ciass AType> void 

GetPolymorphtc iconst TMessacefc message. TOnK'PomterTo<ATvpe><& 
tiilin. Componentlndex inciex) 
35 • template <class AType> void 

GetMonom orphic iconst T Messaged message, AType& hllin. 
(_omponentlndex index) 

The function AddPolymorphic adds a component to a message at 
40 the next available index. The component is placed in the message bodv 
by the process of polymorphic streaming (by calling template <class 
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AType> void Flatten (const AType\TStrearn&) ). It returns the index at 
which the component is placed. 

The function AddMonomorphic adds a component, to a message 
at the next available index. The component is placed in the message 
body by the process or monomorphic streaming (by calling 
AType::operator»=). It returns the index at which the component is 
placed. 

The /unction GetPolymorphic retrieves the component in 
message at index as an object of AType. If the component in message is 
10 of different type, this function throws TTypeMismatch exception. 

The function GetMonomorphic retrieves the component in 
message at index as an object of AType. If the component in message is 
of different type, this function throws TTypeMismatch. exception. 

Another class is related to message properties. This is the 
15 TMessageAddressBundle class which represents an entitv to which a 
message can be sent. Since an address is needed for sending a message, 
the TMessageAddressBundle class is constructed from a message 
receiver address and related attributes as noted in Table 19 below. 
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Tabie 19 



Basic Attributes: 



Multt-threac-sate 


No 


Surrocate / Value-iike 


Value-like 


Multi-mstance-sate 


Yes 


Allows inheritance 


No 


Stahc-sare 


No 


Allocation - stack. heap 


Both 


Shared -memorv-safe 


No 


Abstract /Concrete 


Concrete 



Inherits From: 

MReferenceCounted 



Constants. Enumerators. 7 ypes: 

• enum 

EKind IkTo. kCC. kBCC. kForwardTo. krrom. kForwardFrom. kKeolvTo 
^Recipient. kAlli 

Member Functions: 

TMessaeeAd dress Bundle (const 

TCountedPomterTo<TMessageReceiverAddress>& address. EKind 
kind = kTo) 

TMessaee Address Bundle (TSrreama*: rrom Where i 
TMessaeeAddressBundle (J 

• TCountedPointerTO<TMessageReceiverAddress> 
GetAddress (» const 

• EKind 
GetKand ; ) const 

• bool 

IsValid () const 



The enumerator EKind reflects an attribute to qualify a receiver 
30 address. These can be logically "OR'd" together to form a filter tor use 
in address iteration. One attribute is "kTo" which means a pnmarv 
target of a message. Another attribute is "kCC" which means a 
secondary target ot a message. In addition, kBCC is a blind secondary 
target of a message, kForwardTo is a forwarding target of a message. 
35 kFrom is the originator of a message. kForwardFrom is the address 
from which a message was forwarded. kReplvTo is an address used 
when replying which defaults to kFrom address. kRecipient is a 
predefined filter for (kTo + kCC -r kBCC + kForwardTo). kAll is a 
predefined filter which will match any kind. 
40 The function TMessageAddressBundle constructs a bundle object 

with the specified address and kind. Alternatively, it constructs a 
bundle object by streaming data from the stream fromWhere. 
Alternatively, it creates an invalid bundle. Such a bundle is useful for 
future assignment. A null bundle in a draft message is ignored. 
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The mnction GetAddress returns the address for this bundle. 
Also, the function GetKind returns the kind attribute for this bundle. 
In addition, the function IsValid returns true if the bundle has a valid 
address. 

5 Another class related to message properties is the 

TMessageAddressIterator class (not shown) which provides an iterator 
over the addresses in a message as noted in Table 20 below. 

Table 20 

10 Basic Attributes: 



Multi-thread-safe 


No 


Surroeate/Vaiue-like 


Value-like 


Mult i- instance-sate 


Ves 


Allows inheritance 


No 


Static-safe 


No 


Allocation - stack. heao 


Both 


Shared-mernorv-sare 


No 


Abstract /Concrete 


Concrete 



Inherits From: 
\one 



15 Member Funcnons: 

TMessa^eAd dress Iterator iconst TMessageat message, 
TMessageAddressBundie::EKindSet filter = kTo) 

20 T Message Ad dress iterator () 

• virtual TMessageAddressBundle 
First f) const = 0 

25 • virtual TMessageAddressBundle 

Next ( ) const = 0 

• rool 

^cerator== iconst F Message Ad dress Iterators nchn const 

30 

• r^ool 

operator! = (const TMessageAddress! terator& right) const 



The TMessageAddressIterator function creates an iterator over 
35 the specified message with the specified filter. Alternatively is may 

create an invalid iterator which can be reserved for a future assignment. 

The First function returns the first address in this message. If the 
bin is empty, an invalid TMessageAddressBundle object is returned. 

The Next function returns the next message in this bin. If the bin 
40 is emptv. an invalid TMessageAddressBundle object is returned. 

The operator== and operator!= functions are equality (inequality) 
checks for two iterators. They return a true if both iterators refer to the 
same message, have the same filter, and have the same iteration 
'position'. 
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Some general items to note are that subclass Application 
Programming Interface (API) classes are not needed to use the 
messaging interface classes. The messaging interface API is built on top 
of a messaging framework. The framework requires subclassing of a set 
3 of classes to plug-in a service provider. 

The messaging interface API does not guarantee delivery of a 
message. Different service-providers may have different level of 
delivery guarantees. Some messages may be delivered with loss of data. 
The messaging API defines a message type that will not suffer any 
10 transformation when delivered to a CommonPoint™ recipient 

(TCommonPointMessage class 728). There is a type of message which 
imposes no constraints on the contents or recipients 
(TlnterOperableMessage class 730). However, the messaging interface 
API makes no guarantees about the integrity of instances of the 
1 5 TlnterOperableMessage class 730. 

Both TCommonPointMessage class 728 and 
TlnterOperableMessage class 730 support multiple components of any 
tvpe, as long as the type has the CommonPoint™ type extensions. 
Instances (i.e., objects) of the TlnterOperableMessage class 730 may drop 
20 the components that can not be translated appropriately. 
By iterating over component types using 
T\Iessage::GetComponentType. contents of a message can be 
determined. In addition, the existence of a specific type of component 
i say text) can be checked by using TMessage::DoesContainType. 
25 The messaging interface API does not provide any direct means 

other than construction or reading of received messages for obtaining 
receiver addresses. The goal is to have receiver address manufactured 
by other objects such as people or business cards, etc. 

Client applications may use service-provider-specific address 
30 classes (e.g., the TInternetReceiverAddress class 722) bearing in mind 
that it results in routing a message to that address through only given 
service-provider. 

To keep the different aspects of storage behavior separate from 
each other several bin classes are provided. For example, the 
35 MMessageStore class 702 provides writing behavior (create or copy a 

message in to) for a bin, while the MMessageSource class 704 provides 
reading behavior (iterate over contained messages). This kind of 
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separat 10 n allows for constructing subclasses with various combinations 
or tnese behaviors. 

This separation of behaviors ,s strictly enforced. For examole 
_ MMessageStore provides write-only protocol to message bin. It would 
> break the write-only behavior to provide wait for or iterate protocol in 
this class. Thus, it is not possible to wa.t for (i.e.. kev off on, a messaee 
arrival at a MMessageStore object. 

The following example shown in Table 21 illustrates the use of 
basic functionality provided by the messaging interface. 
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Table 21 



SRevtsiun i Z it 

M essa ein cS .i m v I es C 

Ccpynent C 1995 T absent. Inc. All nents reservrc 

In oroer to rocus on the Messaemc APIs this crocr^m uses a traditional 
C srvjc wi:.n a map ana ciobai runcooni 



10 - ••■ Indudcs 



'imdcj Tdbccnt ME55ACIXG 

*wclude < Tali gent/ Messaeinc, n> 
ID »endu 

a.mdei Taiiceni. INTE RN ETREC E Pv"E RA D DRESS 

*wcluce «-Tauceni/ Interne '.Receiver A ddress.n> 

20 ^ 

*unde t T.ibeen t . DOCUME NT5TOR ECO.NT ENTST REAMER 

^include <Tabeent/Documenc>coreConren streamer. r.> 
■endir 

25 »>mder Tabeent.SAMPLEPROCEDU REMAPS 

•nnduoe <Taiieent/:»ampieProcedureMaps.h> 
•endif 

n *imdet T a b e en t _ E XC EFTIO N.TORM ATT E. R 

3U *uicluae <Tal:eent/ txceoDcnrormatrer n> 



imdc Tabeent MULTIPLE KOOTLOC AT OR 
•include • Taiicenr; MutnrieKootLocator.n.' 
aendu 

»imdet Tali cent BASlCDCXTL'NtENTSTORACE 

include <TAiiccn;/ BasicDcvumenc>coraee.n> 
*endjj 



Message Sending funcnons 



' Sena a messaee comauunc text onlv The messaee can be read within almost 
anv mail s\ stem on anv no«t Text svles will be stripped and some joss of 
text mav occur due to character set trartsianon 



i ctd SenalnterorvrableText e.-nsi TCountedPointerTo<TMessageRece»verAddxess>6r 
address. 

const TSianaardTcxtfc subiec:. 
const TSianaarciText6c texti 

Tlnterooerac'eMessaee me^saeeisubiect.address.teM ». Maice messaee. 
VMessaee^noerGeiOeiauIcenden i- >:>ijcrmtcrnessaec>. . Submit 

• Send a messaee containing tc*t onlv The messaee can onJv r»e rcaa within 
' Commonfoir.r^' 

void SendCommonPotntText -.ccrtst TCounttdPointerTo<TMessaeeReceiverAddre*s>4r address, 
const TJexti: iubwet. 
const TStanaardText* text* 



6D Note TStandardText criects should normailv re handled usine 

AdJLMonomorpmc and CetMonomorphic runcoons. Polymorphic handling 
is needless I v expensive 

-rp. TCommonPomtMessa^e messaeei subiec I -address I. // Mike message 

/U AppendMonomorphtcc messaee. text): •' / Add the text. 

\LMessaeeSender<^etDeiauic^der(i->bubmitirne^saG:ei; // Submit 



* ^ ' ' Send a messaee contauune a sinele CommonPoint"^ obtect The messaee can ontv 

' ' be reaa within CommonPcunr" 



template <ciass ATvre> 

v oid SendOneOtnect iconst T C ountedPointerTo< TMessaee Receiver Address> 6c address, 
const TTexiAt sucxeo. 
const AType& ornect) 

TCommonPoinuMessaee messaeetsubtec<.adaressi // Make messaee 

Append Pol vmorphictmessaee.ODiect i. Add the obiect 
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^t^ies»tfe^e^de^:.CctDetaulc^endcr(>->buomItlmesMee^. . ziubrru: 



O , / Send a messaee containine three CommonPomt 1 * obiects The messaee can oniv 

.'/ be read wio-un CommonJ J oini ,w 
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temDlaw <cJass ATvpe. class BType. class CTvpe> 

void ^dThreeObtects (const TCoumedPomterTo^MessaeeRecetverAddress^ address 
const TStandardTexiAc subiect. 
consi ATypefc obtectl. 
const BTvpefc ob*cct2. 
const CTvpedt obiect3) 



1^ TeommonPointMessage message! subiect -address). / / Make messaee 

A ppendPolvTnorpruci messaee -object 1 J: / 7 Add the ootecrs 

Append Pol vmorphictmessaee.obiecC): 
. \ p pendPol vmorphici messae e .obiec t3 > : 

MMessaeesenden Get Defau I c5enderO->Submiti message;. SuDmit 



Messaee Examination Functions 



' Scan message and return true lit contains a component or the srecmed rvpe 

boo I DoesMessaeeContain (const TMessaeeKetrrenceii message, 
const TTvpeSurroeayedf tareetTvpe) 



cool round = taise. 

:or iir.t t - 0. i < messaee .CounrComponen isi i. »- 
'j imessaee.lsComoonentTvpeitar^tl v-pe.iii 



;ound = true; 
breax. 



re rum found. 



I 



^can messaee and pnnt all text components 

v oid Pnn t Tex KTomponenrs (const TMessa£eReference4c messaee* 

! 

T Standard Te\i text. 

7T\T?c3urToeate texrTvpe(StancT\pelnto(TStandardText)). 
v-^n-oonenOndex count = messaee.CounrComoonentsi ): 

:st tint i - : < count: »•■♦ » 

u imessaee.UCornDonentTvpeirextJ vpe.m 

v>tMonomorpruclmessaee.text.i>. // Extract t«?xt rrom messaee. 
O Pnnt Tex tl text); //Pnnt it. 



fj >en a and Receive Messages 

/ 

void Messaewg^amples (const TCountedPointerTo<TMessa^eReceiverAddress>Ar address, 
const TTexUJc t ex tS abject, 
const TStandardTextfe text Bod v. 
const TTextAt cp Subiect. 
const TdocurnerilReference& document, 
const TTime&t tune, 
const TProceoureMap4c ma pi 

I 

Send an interoperable text message... 
Sendinteroperable Tex t( address .textSubtec t.text Bod\ }; 

Send a text obiect... 

ScndC ommonPoin tTcxtladd ress textSubtect.tex tBod v ). 

Send a messaee containing a single CommonPouit obiect <a document 
bv reterencei... 



SUBSTITUTE SHEET (RULE 26) 



WO 97/22928 



PCT/US96/20536 



10 



15 



20 



30 



40 



45 



50 



60 



70 
75 



-45- 

:>cndOr.eObiectiaddress.cc:>uoiect.docujnenu. 

Send a message containing a smclc CommonPoinr cbiecr la cocumem 
- bv vaiuei... 

^ndC^eOrtccrtadclxess.rpSubtectTDac^ 

' Send a message containing three CommonPcint objects... 

SendTh reeOoiec tsi address . cpSu bie c t.docu m en t . tunc . ma p I ; 

/ Wait for the messaees tc be recteved. F:rsr. eet me receiver 
••' instance. . 

TCountedPcuuerlocMMessaee Receivers receiver = ad dress- >C«etMessage Receiver; i 

■' Now iocp waiune unni we recieve the rrtessace contairunc 
a TProcecureMap .. 

bool Jone = raise. 

rrvpeiurToeate maprypeibtancTvpeuvonTrocedureMap)): 

TMessaceReterence received Message; / .-* Mart with an invabd message 

while {• donc» 

/ / Wait icr a new message to arrive... 

receive dMessaue * receiver- > WattForMessaeeAi ten received Mcssaeei 

' Pnnt ar»v text components in the messaee 

PrtntTexr^cmponentsi receivedMessage*. 

Terminate wnen we vf reoeved tbe message containing tnree 
.* / obiecrs. one ot which is a document . 

il <receivedMessage.CountComponentsi> « = >i 

done = DoesMessaeeContaintreceivedMessaee.maprvpei: 



Maun 



For simDuc.rv we assume tnat this proctam is entered from tne command 
line, and tr.at n is passea a sineie arcument wnich is treated as an 
Internet srv.e mau address All other data is nara cooeo. 

Nonruill\ jresses snoutd be retrieved irom either a business ca:o or rrcn 
the etrectcrv f**rvice> 



int mainiint arcc. cnar'arRvj J> 
bool tailed = large •= 2\ 
it *'. faded: 



, _ TOnlvPomterTo<TDocumencitore> store: 

TC>iivl , omteTTo<T5tanaaxditorageMe<iharusm> mechanism. 



rrv 

/ / Make an Internet address... 

TCounredLPointerTo<TMcssas:eRecetverAddress> address » 
new TlntemetReceiverAddressfTStandardTextiargvl 

' * Make up the remaining arguments to Messa gm sample s... 



TStandardText textSub>ect('~Text Enclosed. ). 

TStandardTe^t ten tBodv( This is a test message rrom CommonPoint "). 

TStandardText crcubtecK CommonPoint Objects Enclosed, i: 
Qn TSeconas time<1234); 

OU T Marble ProcedureMap map; 

// Get a TDocumenLRererence. 

q^. TM u 1 at? le Root Locator local or(" Places 1. 

OD TDirectcrv nomePlacf • locator. FmdFu-stBvNamel DefauItUserHomePlace v ,. 
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mecnanism = p f w TSiandardbtornceMechdmsm.homerhKc MesMeine I ~»rw 
More = new rDocumenctorei mecnarcsm.Onman. p Messaeinc trstDoc 

TX^umrntKeierence aooimcnc -- M ore- >CetUocum^tKe»cnmce, }. 

Now execute tne samples.. 
M ^^^mP'™*dd~ss.te*ou^ 

catch iconst TStandard Exception i e.xcepaon, 

failed = true: 
T5tandaxdTe.xt message. 

1 5 TE.xcepnonFomuiicT xietformanedTexiicjccfpnon. TLocalc. lie-CurremLocale, , 

messages 

OPrmtTexii message:. 
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raiieo = rrue. 

OPr^iTe^lTS.anaAxdTexrt An unknown excepnon was caught. "» 



else 



QPr^.Text.TSra«d^dT e jtrinvabd areumen*. Use MessaguigSamph 



return tailed % \ J 



35 



The present invention can be summarized in reference to FIG. 12 
which is a flowchart of the preferred embodiment object oriented 
programming based messaging interface method for use between a 
client application and a messaging service on a computer system. This 
method is performed by device-implemented steps in a series of distinct 
processing steps 1200-1212 that can be implemented in one or more 
40 processors. 

A message class 724 is provided 1202 which has data members 
and member functions related to a message in the messaging servjee. In 
addition, a message bin class 700 is provided 1204 which has data 
members and member functions related to holding the message. Also, 
a message bin name class 716 is provided 1206 which has data members 
and member functions related to identifying a message bin object 
instantiated from the message bin class 700. Subsequently, a messaging 
interface object for the message is generated 1210 as an instance of one of 
these provided classes (i.e.. the message class 724, the message bin class 
700, or the message bin name class 716. This messaging interlace object 
provides the client application with protocol independent access to the 
messaging service. 

Other classes may be provided 1208 prior to the generating step 
1210 such that other messaging interface-related objects can be generated 
in the generating step 1210. For example, a message address bundle class 
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may be provided 1208 which has data members and member functions 
related to a message receiver address to which the message can be sent 
in the messaging service and related attributes of the message receiver 
add ress. In addition, a message address iterator class mav be provided 
3 1208 which has data members and member functions related to an 
iterator over the addresses. 

A message reference class 712 may be provided 1208 which 
inherits all of the data members and member functions defined by the 
message ciass 724. It further defines data members and member 
10 functions related to locking the message such that the message can not 
be modified. 

A draft message class 726 may be provided 1208 which inherits all 
of the data members and member functions defined bv the message 
class 724. It further defines data members and member functions 

13 related to data integritv and interoperability of the message. Further, an 
OOP-specific message ciass 728 may be provided 1208 which inherits all 
of the data members and member functions defined bv the draft 
message class 726. It further defines data members and member 
functions related to guaranteeing data integrity when delivering the 

20 message to an OOP-based message system. Furthermore, an 

interoperable message class 730 may be provided 1208 which inherits all 
of the data members and member functions defined bv the draft 
message class 726. It further defines data members and member 
functions related to guaranteeing data interoperabilitv when delivering 

23 the message to a non-OOP-based message svstem. 

A message store class 702 may be provided 1208 which inherits all 
of the data members and member functions defined bv the message.bin 
ciass 700. It further defines data members and member functions 
related to protocols for storing the message into a message store object 

30 instantiated from the message store class 702. Further, a message sender 
class 706 may be provided 1208 which inherits all of the data members 
and member functions defined by the message store ciass 702. It further 
defines data members and member functions related to protocols for 
submitting and sending the message from the client application to the 

35 messaging service. In addition, a message source class 704 may be 
provided 1208 which inherits all of the data members and member 
functions defined by the message bin class 700. It further defines data 
members and member functions related to protocols for retrieving the 
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message from a message source object instantiated from the message 
source class 704. This allows a file system message store class 714 to be 
provided 1208 which inherits all of the data members and member 
functions defined by the message sender class 706 and the 
5 MMessageSource class 704. It further defines data members and 

member functions related to protocols for storing, accessing and sending 
the message where the message is stored in a file system directory in a 
storage device 120 of the computer svstem. 

A message source class 704 alone (i.e.. without the message 

10 sender class 706 and the message source class 704) may be provided 1208 
which inherits all of the data members and member functions defined 
by the message bin class 700. It further defines data members and 
member functions related to protocols for retrieving the message from a 
message source object instantiated from the message source class 704. 

15 Further, a message receiver class 708 may be provided 1208 which 

inherits all of the data members and member functions defined by the 
message source class 704. It further defines data members and member 
functions related to protocols for receiving the message at a receiver 
address from the messaging service and providing the message to the 

20 client application. Alternatively, a message iterator class 710 may be 

provided 1208 which has data members and member functions related 
to iteration functionality over a collection of messages from a message 
source object instantiated from the message source class 704. 

A file system message store name class 714 mav be provided 1208 

25 which inherits all of the data members and member functions defined 
by the message bin name class 716. It further defines data members and 
member functions related to identifying a fiie system message store 
object instantiated from the file system message store class 714. 

A MessageReceiverAddress class 718 may be provided 1208 which 

30 inherits all of the data members and member functions defined by the 
message bin name class 716. It further defines data members and 
member functions related to identifying a message receiver object 
instantiated from the message receiver class 708. Also, a internet 
receiver address class 722 may be provided 1208 which inherits all of the 

35 data members and member functions defined by the 

MessageReceiverAddress class 718. It further defines data members and 
member functions related to identifying an RFC-822 compliant Internet 
mailbox address. 
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This messaging interface process mav be implemented in a 
computer system bv storing the classes in a storage device 120 and using 
a processor 110 in conjunction with RAM 114 and /or ROM to generate 
objects from the stored classes. A communications adapter 134 mav 
5 communicate a message object, instantiated from the message class 724, 
between the computer system and other computer svstems operatively 
coupled together on a communication network. 

In addition, a program storage device may be created which is 
readable by a computer system tangibly embodying a program of 

10 instructions executable by the computer system. This program of 

instructions would perform one or more parts of the object oriented 
programming based messaging interface method described about. 

It is to be understood that even though numerous characteristics 
and advantages of various embodiments of the present invention have 

15 been set forth in the foregoing description, together with details of the 
structure and function of various embodiments of the invention, this 
disclosure is illustrative only, and changes may be made in detail, 
especially in matters of structure and arrangement of parts within the 
principles of the present invention to the full extent indicated bv the 

20 broad general meaning of the terms in which the appended claims are 
expressed. For example, the actual names or division or functions may 
be changed between the OOP ciasses and objects, detailed above, while 
maintaining substantially the same functionality without departing 
from the scope and spirit of the present invention. 
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Claims 

What is claimed is: 

5 1. An object oriented programming (OOP) based messaging 

interface method for use between a client application and a 
messaging service on a computer system, comprising the steps of: 
(a) providing a message class which has data members and 
member functions related to a message in the messaging 
10 service; 

fb) providing a message bin class which has data members and 
member functions related to holding the message; 

(c) providing a message bin name class which has data 

members and member functions related to identifying a 

13 message bin object instantiated from the message bin class; 

and 

(d) generating a messaging interface object for the message as 
an instance of one of the provided classes, the messaging 
interface object furnishing the client application with 
protocol independent access to the messaging service. 

2. The messaging interface method of claim 1 further comprising 
the step of providing a message address bundle class which has 
data members and member functions related to a message 
receiver address to which the message can be sent in the 
messaging service and related attributes of the message receiver 
address. 
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The messaging interface method of claim 1 further comprising 
the step of providing a message address iterator class which has 
data members and member functions related to an iterator over 
the addresses. 
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4. The messaging interface method of claim 1 further comprising 
the step of providing a message reference class which inherits all 
of the data members and member functions defined by the 
message class and further defines data members and member 
functions reiated to locking the message such that the message 
can not be modified. 

5. The messaging interface method of claim 1 further comprising 
the step of providing a draft message class which inherits all of 
the data members and member functions defined by the message 
class and further defines data members and member functions 
reiated to data integrity and interoperability of the message. 

6. The messaging interface method of ciaim 5 further comprising 
15 th e step of providing an OOP-specific message class which 

inherits all of the data members and member functions defined 
by the draft message class and further defines data members and 
member functions related to guaranteeing data integrity when 
delivering the message to an OOP-based message system. 
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7. The messaging interface method of claim 5 further comprising 
the step of providing an interoperable message class which 
inherits all of the data members and member functions defined 
by the draft message class and further defines data members and 
member functions related to guaranteeing data interoperabilitv 
when delivering the message to a non-OOP-based message 
system. 

8. The messaging interface method of claim 1 further comprising 
the step of providing a message store class which inherits all of 
the data members and member functions defined by the message 
bin class and further defines data members and member 
functions related to protocols for storing the message into a 
message store object instantiated from the message store class. 



DMCfWin. ^\htr\ ftTMOOO, 
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The messaging interface method of claim 8 further comprising 
the step or providing a message sender class which inherits all of 
the data members and member functions defined by the message 
store ciass and further defines data members and member 
functions related to protocols for submitting and sending the 
message from the client application to the messaging service. 

The messaging interface method of claim 9 further comprising 
the steps of: 

(a) providing a message source class which inherits all of the 
data members and member functions defined by the 
message bin class and further defines data members and 
member functions related to protocols for retrieving the 
message from a message source object instantiated from 
the message source class: and 

(b) providing a file system message store ciass which inherits 
all of the data members and member functions defined by 
the message sender class and the message source class and 
further defines data members and member functions 
related to protocols for storing, accessing and sending the 
message where the message is stored in a file svstem 
directory in a storage of the computer system. 

The messaging interface method of claim i further comprising 
the step or providing a message source ciass which inherits all of 
the data members and member functions defined by the message 
bin class and further defines data members and member 
functions related to protocols for retrieving the message from a 
message source object instantiated from the message source class. 

The messaging interface method of claim 11 further comprising 
the step of providing a message receiver class which inherits all 
of the data members and member functions defined bv the 
message source ciass and further defines data members and 
member functions related to protocols for receiving the message 
at a receiver address from the messaging service and providing 
the message to the client application. 
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13. The messaging interface method of claim 11 further comprising 
the step of providing a message iterator ciass which has data 
members and member functions related to iteration functionality 
over a collection of messages from a message source object 

5 instantiated from the message source class. 

14. The messaging interface method of claim 10 further comprising 
the step or providing a file system message store name class 
which inherits ail of the data members and member functions 

0 defined by the message bin name class and further defines data 

members and member functions related to identifying a file 
system message store object instantiated from the file system 
message store class. 

5 15. The messaging interlace method or claim 12 further comprising 
the step of providing a message receiver address ciass which 
inherits all of the data members and member functions defined 
by the message bin name class and further defines data members 
and member functions related to identifying a message receiver 

0 object instantiated from the message receiver class. 

16. The messaging interface method of claim 15 further comprising 
the step of providing a internet receiver address class which 
inherits all of the data members and member functions defined 
by the message receiver address class and further defines data 
members and member functions reiated to identifying an RFC- 
S22 compliant Internet mailbox address. 
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I- A program storage device readable by a computer svstem taneiblv 
embodymg a program or instructions executable bv the computer 
system to perform an object oriented programming (OOP) based 
messaging interface method tor use between a client application 
and a messaging service on the computer system, the method 
comprising the steps of: 

fa) providing a message class which has data members and 
member funchons related to a message in the messaging 
service; ' 

10 (b> Providing a message bin class which has data members and 

member functions related to holding the message; 
(c) providing a message bin name class which has data 

members and member functions related to identifying a 
message bin object instantiated from the message bin class; 

1:1 and 

fd) generating a messaging interface object for the message as 
an instance of one of the provided classes, the messaging 
interface object furnishing the client application with 
protocol independent access to the messaging service. 



20 
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The program storage device or claim 17 wherein the method 
further comprises the step of providing a message address bundle 
class which has data members and member functions related to a 
message receiver address to which the message can be sent in the 
messaging service and related attributes of the message receiver 
address. 



19. The program storage device of claim 17 wherein the method 
further comprises the step of providing a message address iterator 

30 class which has data members and member functions related to 

an iterator over the addresses. 

20. The program storage device of claim 17 wherein the method 
further comprises the step of providing a message reference class 

35 which inherits all of the data members and member functions 

defined by the message class and further defines data members 
and member functions related to locking the message such that 
the message can not be modified. 
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The program storage device of ciaim 17 wherein the method 
further comprises the step or providing a draft message class 
which inherits aii of the data members, and member functions 
defined by the message class and further defines data members 
and member functions related to data integritv and 
interoperability of the message. 

The program storage device of claim 21 wherein the method 
further comprises the step of providing an OOP-specific message 
class which inherits all of the data members and member 
functions defined by the draft message class and further defines 
data members and member functions related to guaranteeing 
data integrity when delivering the message to an OOP-based 
message system. 

The program storage device of claim 21 wherein the method 
further comprises the step of providing an interoperable message 
class which inherits all of the data members and member 
functions defined by the draft message class and further defines 
data members and member functions related to guaranteeing 
data interoperability when delivering the message to a non-OOP- 
based message system. 

The program storage device of claim 17 wherein the method 
further comprises the step of providing a message store class 
which inherits all of the data members and member functions 
defined by the message bin class and further defines data 
members and member functions related to protocols for storing 
the message into a message store object instantiated from the 
message store class. 
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25. The program storage device or claim 24 wherein the method 
further comprises the step of providing a message sender class 
which inherits all of the data members and member functions 
defined by the message store class and further defines data 

5 members and member functions related to protocols for 

submitting and sending the message from the client application 
to the messaging service. 

26. The program storage device of claim 25 wherein the method 
10 further comprises the steps of: 

(a) providing a message source class which inherits all of the 
data members and member functions defined by the 
message bin class and further defines data members and 
member functions related to protocols for retrieving the 
message from a message source object instantiated from 
the message source ciass; and 

(b) providing a file system message store class which inherits 
all of the data members and member functions defined by 
the message sender class and the message source class and 
further defines data members and member functions 
related to protocols for storing, accessing and sending the 
message where the message is stored in a file svstem 
directory in a storage of the computer system. 

27. The program storage device of claim 17 wherein the method 
further comprises the step of providing a message source class 
which inherits all of the data members and member functions 
defined by the message bin class and further defines data 
members and member functions related to protocols for 
retrieving the message from a message source object instantiated 
from the message source class. 
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The program storage device or claim 27 wherein the method 
further comprises the step of providing a message receiver class 
which inherits all of the data members and member functions 
defined by the message source class and further defines data 
members and member functions related to protocols for 
receiving the message at a receiver address from the messaging 
service and providing the message to the client application. 

The program storage device of claim 27 wherein the method 
further comprises the step of providing a message iterator class 
which has data members and member functions related to 
iteration functionality over a collection of messages from a 
message source object instantiated from the message source class. 

The program storage device of claim 26 wherein the method 
further comprises the step of providing a file system message 
store name class which inherits all of the data members and 
member functions defined by the message bin name class and 
further defines data members and member functions related to 
identifying a file system message store object instantiated from 
the file system message store class. 

The program storage device of claim 2S wherein the method 
rurther comprises the step of providing a message receiver 
address class which inherits all of the data members and member 
functions defined by the message bin name class and further 
defines data members and member functions related to 
identifying a message receiver object instantiated from the 
message receiver class. 

The program storage device of claim 31 wherein the method 
further comprises the step of providing a internet receiver 
address class which inherits all of the data members and member 
functions defined by the message receiver address class and 
further defines data members and member functions related to 
identifying an RFC-S22 compliant Internet mailbox address. 
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An object oriented programming (OOP) based messaging 
interface between a client application and a messaging service for 
a computer system, comprising: 

(a) a storage device, in the computer system, which stores 
OOP-based classes, the classes, including: 

(i) a message class which has data members and 
member functions related to a message in the 
messaging service; 

(ii) a message bin class which has data members and 
member functions related to holding the message; 
and 

(iii) a message bin name class which has data members 
and member functions related to identifying a 
message bin object instantiated from the message 
bin ciass; and 

fb) a processor, operativeiy coupled to the storage device, 
which generates a messaging interface object for the 
message as an instance of a class stored in the storage 
device, the messaging interface object furnishing the client 
20 application with protocol independent access to the 

messaging service. 

34. The messaging interface of claim 33 further comprising a 

communication adapter, operativeiy coupled to the processor, 
2:> which communicates a message object, instantiated from the 

message class, between the computer system and other computer 
systems operativeiy coupled together on a communication 
network. 

30 35. The messaging interface of claim 33 wherein the storage device 
further includes a message address bundle class which has data 
members and member functions related to a message receiver 
address to which the message can be sent in the messaging 
service and related attributes of the message receiver address. 

35 
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36. The messaging interface of claim 33 wherein the storage device 
further includes a message address iterator class which has data 
members and member functions related to an iterator over the 
addresses. 

3 

37. The messaging interface of claim 33 wherein the storage device 
further includes a message reference class which inherits all of 
the data members and member functions defined by the message 
class and further defines data members and member functions 

10 related to locking the message such that the message can not be 

modified. 

38. The messaging interface of claim 33 wherein the storage device 
further includes a draft message class which inherits all of the 

15 data members and member functions defined bv the message 

class and further defines data members and member functions 
related to data integrity and interoperability of the message. 

39. The messaging interface of claim 38 wherein the storage device 
20 further includes an OOP-specific message class which inherits all 

of the data members and member functions defined by the draft 
message class and further defines data members and member 
functions related to guaranteeing data integrity when delivering 
the message to an OOP-based message svstem. 

25 

40. The messaging interface of claim 38 wherein the storage device 
further includes an interoperable message class which inherits all 
of the data members and member functions defined by the draft 
message class and further defines data members and member 

30 functions related to guaranteeing data interoperability when 

delivering the message to a non-OOP-based message system. 

41. The messaging interface of claim 33 wherein the storage device 
further includes a message store class which inherits all of the 

35 data members and member functions defined by the message bin 

class and further defines data members and member functions 
related to protocols for storing the message into a message store 
object instantiated from the message store class. 
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The messaging interface of claim 41 wherein the storage device 
further includes a message sender class which inherits all of the 
data members and member functions defined by the message 
store class and further defines data members and member 
functions related to protocols for submitting and sending the 
message from the client application to the messaging service. 

The messaging interface of claim 42 wherein: 

(a) the storage device further includes a message source class 
which inherits all of the data members and member 
functions defined by the message bin class and further 
defines data members and member functions related to 
protocols for retrieving the message from a message source 
object instantiated from the message source class; and 

(b) the storage device further includes a file system message 
store class which inherits all of the data members and 
member functions defined by the message sender class and 
the message source class and further defines data members 
and member functions related to protocols for storing, 
accessing and sending the message where the message is 
stored in a file system directory in a storage of the 
computer system. 



The messaging interface of claim 33 wherein the storage device 
further includes a message source class which inherits all of the 
data members and member functions defined by the message bin 
class and further defines data members and member functions 
related to protocols for retrieving the message from a message 
source object instantiated from the message source class. 

The messaging interface of claim 44 wherein the storage device 
further inciudes a message receiver class which inherits all of the 
data members and member functions defined bv the message 
source class and further defines data members and member 
functions related to protocols for receiving the message at a 
receiver address from the messaging service and providing the 
message co the client application. 
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The messaging interface of claim 44 wherein the storage device 
further includes a message iterator class which has data members 
and member functions related to iteration functionality over a 
collection of messages from a message source object instantiated 
from the message source ciass. 

The messaging interface of claim 43 wherein the storage device 
further includes a file system message store name class which 
inherits all of the data members and member functions defined 
by the message bin name class and further defines data members 
and member functions related to identifying a file svstem 
message store object instantiated from the file system message 
store class. 

The messaging interface of claim 45 wherein the storage device 
further includes a message receiver address class which inherits 
all of the data members and member functions defined by the 
message bin name class and further defines data members and 
member functions related to identifying a message receiver object 
instantiated from the message receiver class. 

The messaging interface of claim 48 wherein the storage device 
further includes a internet receiver address ciass which inherits 
ail or the data members and member runctions defined bv the 
message receiver address class and further defines data members 
and member functions related to identifving an RFC-S22 
compliant Internet mailbox address. 
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